Introduction: 


The Lyndon B. Johnson Space Center (JSC) of the National Aeronautics and Space 
Administration (NASA) is the world center for manned spaceflight. This entity of the U.S. 
Government’s space program is home to around 10,000 employees dedicated to furthering space 
exploration. Mission operations, engineering and research, and safety and mission assurance are 
three major functions, among a variety of others, that are performed at JSC. NASA is a unique 
place to work because it is the sole operator of the products it designs and engineers. 

The Mission Operations Directorate (MOD) is responsible for the training, planning and 
performance of all U.S. manned operations in space. Within this directorate all responsibilities 
are divided up into divisions. The EVA, Robotics & Crew Systems Operations Division 
performs ground operations and trains astronauts to carry out some of the more “high action” 
procedures in space. For example they orchestrate procedures like EVAs, or Extravehicular 
Activities (spacewalks), and robotics operations external to the International Space Station (ISS). 
The robotics branch of this division is responsible for the use of the Mobile Servicing System 
(MSS). This system is a combination of two robotic mechanisms and a series of equipment used 
to transport them on the ISS. The MSS is used to capture and position visiting vehicles, 
transport astronauts during EVAs, and perform external maintenance tasks on the ISS. This 
branch consists of two groups which are responsible for crew training and flight controlling, 
respectively. 

My first co-op tour took place Fall 2013. During this time I was given the opportunity to work in 
the robotics operations branch of the Mission Operations Directorate at NASA’s Johnson Space 
Center. I was given a variety of tasks that encompassed, at a base level, all the aspects of the 
branch. 
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Work Environment: 


In the Robotics Operations branch I was surrounded by a variety of people with different skill 
sets. The one widespread common background is that almost every person has at least a 
Bachelors of Science in some kind of Engineering or STEM major. In this branch there are three 
specialties; analysts, instructors, and flight controllers. Fortunately I was given exposure to all 
three specialties. I worked closely with analysts on mass property timelines. The instructors 
helped me learn the basics of how an astronaut leams to operate the MSS and how to teach 
complex concepts to different kinds of learners. Lastly, I worked on a project that, throughout 
the semester, required extensive collaboration with flight controllers. 

Most of my time was spent interacting with technical experts to receive guidance and 
information required to make my projects successful. I met daily with the group manager to 
check on the progress of my projects. During this time we would discuss any questions I had 
from the day before and we would run down through what was expected for me to accomplish 
that day. Most of my day was spent meeting with various technical experts in one-on-one 
settings, with a few presentations and panel discussions on the direction of my project. 

When not in meetings I was in computer labs with special capabilities. The digital skills 
machines were equipped with software for 3D visualization and real robotics hand controllers to 
teach a student how to fly a robotic arm. The Robotics Planning Facility (RPF) was a lab full of 
computers where the 3D models of the ISS are edited, where procedures are tested and where 
analysis is perfonned. 

The employees in this branch typically have more work than they can finish and are always 
prioritizing. The standard of work is at a maximum, as lives are often at stake. They work very 
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hard without complaint because they all love what they do. This creates a great atmosphere and 
motivated me to work hard and with a high level of precision, while having lots of fun. 

The co-op culture at JSC is very unique. The co-ops lead the governing body that organizes all 
of the student employees’ (co-ops, interns and student-contractors) many groups and activities. I 
was actively involved in nearly all of these groups as the leader of all the committee chairs (role 
similar to “president”). In this role I was able to re-write the by-laws for future student 
employees to benefit. Lastly, I volunteered for a local dog shelter on the weekends alongside a 
few co-ops and JSC full-time employees. 

Technical Summary: 

During my time in Robotics Operations I worked on two major projects, an early warning system 
for flight controllers and an analysis of vehicles visiting Station. I also completed the generic 
robotics training (GRT) flow. 

Upon beginning work in DX2 I was made aware of an issue with current procedures for on-call 
flight controllers. If there was a major error or malfunction with the robotics on station one of 
the core flight controllers would be monitoring the systems and call the on-call ROBO under 
certain circumstances. An automated system could be put in place to give the ROBO an early 
warning along with pertinent information before this call came through. A solution for this had 
been in its early stages when I arrived. A new coding language, ISPbeep, had been written that 
could send emails due to whatever PUI change the script writer chose. Then the DX2 co-op 
before me explored some of the capabilities of this language in the scope of the problem at hand. 
When I arrived there were some scattered capabilities and some basic if statements that defined 
the possible states of most of the status PUIs. 
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From the beginning, I worked very closely with my supervisor who was as actively involved in 
this project as I was. Our first major hurdle was to find out what this script would need to 
include to effectively accomplish the two major goals: alert and inform the on-call ROBO. 

Once I had taken a couple weeks to familiarize myself with ISPbeep and the work my 
predecessor had done we began to interview and have panel discussions with the certified 
ROBOs. From this infonnation gathering we were able to determine that certain RAL messages 
accounted for all of the major reasons why a ROBO would be called, and that more could easily 
be added later. Once this list and a list of information desired for the status update was compiled 
the script had to be written. 

I then used watchdog logic and a series of trial and error experiments utilizing a .sitf file to create 
the final product, called Custos. In the end, Custos would be in constant communication with the 
ISP servers in the MCC, reading live telemetry from Station. 

The logic of the Custos script is quite easy to follow. First it read in the PUIs required for the 
status and alert messages, and assigned them to variables. Then two subfunctions were created. 
One to format and prepare an email with all the status information and a list of RAL messages in 
alarm. The other, to format and prepare a brief text message containing the RAL message in 
alarm and to refer to the email for more information. These both would be set to be sent out to 
the on-call ROBO. Once these sub functions had been defined, the watchdog logic was put into 
place. This consisted of a series of if loops that would be triggered when one of the RAL 
messages in the predefined list went into alarm. Once triggered it would kill the program and 
send both the status email and the text message. 
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While the logic is easy to follow, there were many hurdles in the implementation of ISPbeep to 
achieve all of the desired features. Despite those hurdles, Custos is now operational and is 
considered, overall, a success. However, some secondary desired abilities of Custos remain 
unfinished. There needs to be a user-friendly GUI to activate and deactivate the system from 
console computers. Also, there should be some way to have a system that chooses the email 
address and phone number of the on-call ROBO without having to manually edit the code each 
shift change. 

Historically GNC has asked DX2 to run a mass properties timeline (MPT) each time any vehicle 
was birthed with Station. This required a lot of valuable analysis time and seemed to my 
supervisor to be unnecessary, because each operation was almost identical. I was tasked to 
provide some key piece of evidence to support this theory. 

I pulled the recorded joint angles for the capture and release of every visiting vehicle that 
required birthing since the beginning of ISS. I then converted this to a format the MPT program 
could read. Running MPT through RPS with the vehicle’s mass entered into system made a 
clear visual of the COM of the combined SSRMS and vehicle throughout the maneuver. This 
was easy to do for a single maneuver, but to show how similar each maneuver was, they had to 
be run all in the same file. This brought to the surface a serious bug in the program that made the 
files grow to unmanageable sizes and crash RPS. After a few discussions with the developers, a 
solution was found and the project was able to be completed for both capture and release of all 
visits by Dragon, HTV and Cygnus. 

These visuals were then displayed on a branch webpage. Along with the MPT visuals, 
information regarding the exact timing of the maneuvers and the corresponding attitude changes 
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of Station during those times were also included. In the future this webpage can be used to help 
explain to GNC that some of this analysis may not be necessary. 

The generic robotics training (GRT) consisted of a series of classes which teach the student the 
basics of how all robotic arms function. You start out with the basics of 3D coordinate frames 
and the how to use and understand the various other frames used in commanding robotics. 
Gradually the student works his/her way up to working on skill training computers using hand 
controllers and robotics training software. These skill trainers help develop a perception of 
things in 3D space using only a few camera angles. Then the student has to monitor clearances 
and gauges to detennine if the operation being perfomed is safe. Once these skills have been 
honed through the training flow, an examination encompassing everything the student has 
learned is administered. Passing this exam completes the training flow and certifies a student to 
continue on the instructor track, and begin to learn how to teach the GRT classes. 

Conclusion: 

My first co-op tour at NASA’s Johnson Space Center was an eye opening extremely fulfilling 
experience. I have seen and done things, that previously, I could only imagine. Most 
importantly, what I saw at JSC, with respect to quality of life and happiness, caused a shift in my 
employment after graduation requirements. I also felt like I gained technical experience while 
making a legitimate contribution to my branch. Overall, I could not have asked to gain any more 
out of a co-op tour. 

My next tour will be this summer, 2014. During this tour I will be in the engineering directorate, 
working on future spacesuit designs. I have also set up my following tour, in the Spring of 2015, 
back in the EVA, Robotics & Crew Systems Operations Division of MOD. This third semester 
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at JSC will be in the Neutral Buoyancy Lab, working with design and simulations that take place 
at that time. 

I currently plan to graduate in May of 2016, depending on class schedules and with the 
possibility for additional tours at JSC. At that time I will have to make career decisions that I am 
currently unprepared to make. That being said, I can see myself having a long and happy career 
as a Civil Servant for NASA. I am very excited for future tours and to be a small part in 
furthering human space exploration. 
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